Computer architecture utilizing layered device drivers

ABSTRACT

A computer storage architecture utilizing layered device drivers enables a user to create and install a device driver into a computer. The device driver is installed into the storage unit through a registration process. In order to permit the user to specify a device driver stack for the device driver and specify the relative position of the device driver within the device driver stack, a novel layered device driver registration system that is separate from a operating system device driver registration system is utilized. The layered device driver registration system enables the user to install one or more device drivers and to specify the placement of each device driver relative to the other device drivers in various device driver stacks. The layered device driver registration system allows a device driver to be dynamically inserted into or removed from a particular device driver stack.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/375,331, filed Aug. 17, 1999, the full disclosure of which is herebyincorporated by reference herein.

The following commonly-owned United States patent applications may berelated to the subject patent application, and are hereby incorporatedby reference in their entireties:

Application Ser. No. 09/375,860, filed Aug. 17, 1999, entitled REMOTEMIRRORING SYSTEM, DEVICE, AND METHOD, in the names of Dennis Duprey andJeffrey Lucovsky, issued as U.S. Pat. No. 6,671,705; and

Application Ser. No. 09/376,173 filed Aug. 17, 1999, entitled SYSTEM,DEVICE, AND METHOD FOR INTERPROCESSOR COMMUNICATION IN A COMPUTERSYSTEM, in the names of Alan L. Taylor, Jeffrey Lucovsky, and Karl Owen.

FIELD OF THE INVENTION

The present invention relates generally to computer systems, and moreparticularly to a computer architecture utilizing layered devicedrivers.

BACKGROUND OF THE INVENTION

A typical computer includes various physical and logical devices. Eachdevice is typically supported through a device driver. The device driverdefines the device (in the case of a logical device), and allows theother components in the computer to utilize the device.

Very often, a number of device drivers are used in combination in astack configuration. When organized in a stack configuration, aparticular device driver consumes services from the device driver belowit in the stack and exports services to the device driver above it inthe stack. For convenience, each device driver in a device driver stackis referred to as a layered device driver (LDD). Each LDD emulates adevice. A LDD “exports” a device to the LDD above it in the devicedriver stack and “consumes” the device that is exported by the LDD belowit in the device driver stack. A LDD is “bound” to the LDD below it inthe device driver stack.

The U.S. Pat. No. 5,802,364 entitled METADEVICE DRIVER RENAME/EXCHANGETECHNIQUE FOR A COMPUTER SYSTEM INCORPORATING A PLURALITY OF INDEPENDENTDEVICE DRIVERS, issued on Sep. 1, 1998 in the names of Steven T.Senator, Dale R. Passmore, and Robert S. Gittins, which is herebyincorporated by reference in its entirety, describes a LDD architecturefor use in a storage device. This patent addresses altering aprior-established driver hierarchy, and describes a LDD architecture inwhich each LDD is able to operate independently of the other LDDswithout knowledge of the private data structures of any of the otherLDDs.

LDDs are installed into the computer through a registration process.Briefly, the operating system includes a device driver registrationsystem that enables a LDD to be initialized and installed into theoperating system. The user can specify the relative position of each LDDwithin the device driver stack.

For example, the Windows NT operating system includes an operatingsystem device driver registration system. Specifically, the Windows NToperating system maintains a list of device drivers and theircorresponding parameters in the System\CurrentControlSet\Services file.Using the information in the System\CurrentControlSet\Services file, theWindows NT operating system loads the device drivers into the operatingsystem in a specified order. Such loading provides for orderlyinitialization of the device drivers.

One problem with the operating system device driver registration systemis that it does not support multiple device driver stacks, which arenecessary or desirable in some computer applications. Thus, theoperating system device driver registration system does not allow theuser to specify a particular device driver stack and a relative positionin the device driver stack for each LDD.

Thus, there is a need for a layered device driver registration systemthat allows the user to specify a particular device driver stack and arelative position in the device driver stack for each LDD is needed, andalso allows a layered device driver to be dynamically inserted into orremoved from a particular device driver stack.

SUMMARY OF THE INVENTION

In accordance with one aspect of the present invention, a layered devicedriver registration system is used in conjunction with an operatingsystem device driver registration system to enable a user to associate adevice driver with one of a number of device driver stacks and toconfigure the relative position of the device driver within the devicedriver stack. The layered device driver registration system includes adriver list and a driver order list. In order to install a devicedriver, the device driver is added to the driver list, and the relativeposition of the device driver is indicated within the driver order list.

In accordance with another aspect of the invention, a layered devicedriver is inserted into a device driver stack between an upper devicedriver and a lower device driver by suspending input/output operationsfor the device driver stack, unbinding the upper device driver from thelower device driver, binding the new device driver to the lower devicedriver, binding the upper device driver to the new device driver, andrestarting input/output operations for the device driver stack.

In accordance with yet another aspect of the invention, a layered devicedriver is removed from a device driver stack, and specifically frombetween an upper device driver and a lower device driver, by suspendinginput/output operations for the device driver stack, unbinding the upperdevice driver from the unwanted device driver, unbinding the unwanteddevice driver from the lower device driver, binding the upper devicedriver to the lower device driver, and restarting input/outputoperations for the device driver stack.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects and advantages of the invention will beappreciated more fully from the following further description thereofwith reference to the accompanying drawings wherein:

FIG. 1 shows the types of information contained in an exemplary driverslist in accordance with an embodiment of the present invention;

FIG. 2 shows the types of information contained in an exemplary driverorder list in accordance with an embodiment of the present invention;

FIG. 3A is a block diagram showing an exemplary device driver stack inaccordance with an embodiment of the present invention;

FIG. 3B is a block diagram showing an exemplary device driver stack inwhich an upper device driver is unbound from a lower device driver forinserting a device driver in the device driver stack in accordance withan embodiment of the present invention;

FIG. 3C is a block diagram showing an exemplary device driver stack inwhich the device driver is bound to the lower device driver inaccordance with an embodiment of the present invention;

FIG. 4 is a block diagram showing an exemplary device driver stack inwhich the upper device driver is bound to the device driver inaccordance with an embodiment of the present invention;

FIG. 5 is a logic flow diagram showing exemplary logic for inserting adevice driver into the device driver stack in accordance with anembodiment of the present invention;

FIG. 6A is a block diagram showing an exemplary device driver stackincluding a device driver in accordance with an embodiment of thepresent invention;

FIG. 6B is a block diagram showing an exemplary device driver stack inwhich an upper device driver is unbound from the device driver forremoving the device driver from the device driver stack in accordancewith an embodiment of the present invention;

FIG. 6C is a block diagram showing an exemplary device driver stack inwhich the device driver is unbound from a lower device driver forremoving the device driver from the device driver stack in accordancewith an embodiment of the present invention;

FIG. 7 is a block diagram showing an exemplary device driver stack inwhich the upper device driver is bound to the lower device driver inaccordance with an embodiment of the present invention;

FIG. 8 is a logic flow diagram showing exemplary logic for removing adevice driver from the device driver stack;

FIG. 9 is a block diagram showing an exemplary computer storage systemin accordance with an embodiment of the present invention;

FIG. 10 is a block diagram showing an exemplary storage unit inaccordance with an embodiment of the present invention;

FIG. 11 is a block diagram showing the overall software- architecture ofexemplary storage processor software in accordance with an embodiment ofthe present invention;

FIG. 12 is a block diagram showing a number of relevant components of astorage processor in accordance with an embodiment of the presentinvention;

FIG. 13 is a block diagram showing a number of relevant components fordisk configuration under the Windows NT operating system;

FIG. 14 is a block diagram showing a number of relevant disk-sidecomponents in accordance with an embodiment of the present invention;

FIG. 15 is a block diagram showing a number of relevant host-sidecomponents in accordance with an embodiment of the present invention;and

FIG. 16 is a block diagram showing a re-layered device driver inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

An embodiment of the present invention utilizes a layered device driver(LDD) registration system in conjunction with the operating systemdevice driver registration system in order to enable the user to installone or more LDDs and to specify the placement of each LDD relative tothe other LDDs in various device driver stacks. The LDD registrationsystem also allows a LDD to be dynamically inserted into or removed froma particular device driver stack.

The LDD registration system keeps track of the LDDs that are installedand the relationships between the LDDs using two lists. Specifically, aDrivers list identifies the LDDs that are installed, and a DriverOrderlist specifies the relative position of the LDDs.

The Drivers list includes a DriverCount indicating the number of LDDs inthe list, and also includes a key for each LDD. The key includes anordinal number, a driver name, a library name, a stack operationsparameter, and an I/O initiator parameter. The ordinal number indicatesthe driver number within the Drivers list (not the relative position ofthe LDD within a device driver stack). The driver name specifies the LDDname that is used by the LDD registration system to identify the LDD.The library name specifies the name of an administrative library that isassociated with the LDD. The stack operations parameter identifiescertain LDD administrative operations that would alter the globalmapping of devices in the device driver stack. The I/O initiatorparameter indicates whether the LDD initiates I/O, in which case thedriver must be instructed to quiesce I/O for the device driver stackwhen changes are made to that device driver stack. FIG. 1 shows anexemplary Drivers list including a DriverCount and a key.

The DriverOrder list includes a DriverCount indicating the number ofLDDs in the list, and also includes a key for each LDD. The key includesan ordinal number and a driver name. The ordinal number indicates therelative position of the LDD within the device driver stack. FIG. 2shows an exemplary DriverOrder file including a DriverCount and a key.

In order to utilize a particular device, the corresponding LDD isinstalled at a specified relative position in a specified device driverstack, specifically between an upper LDD and a lower LDD already in thedevice driver stack. Installing the new LDD into the device driver stackinvolves suspending I/O operations for the device driver stack,unbinding the upper LDD from the lower LDD, binding the new LDD to thelower LDD, binding the upper LDD to the new LDD, and restarting I/Ooperations for the device driver stack.

FIG. 3A shows an exemplary device driver stack including three LDDs,namely TCD (302), Driver Z (306), and Driver X (310). Driver X (310)exports Device X (308). Driver Z (306) is bound to Device X (308), andexports Device Z (304). TCD (302) consumes Device Z (304).

In order to insert a Device Y into the device driver stack betweenDevice Z (304) and Device X (308), a Driver Y is inserted into thedevice driver stack between Driver Z (306) and Driver X (310). First,I/O operations are suspended for the device driver stack. Then, Driver Z(306) is unbound from Device X (308). Next, Driver Y is bound to DeviceX (308), and exports Device Y. Finally, Driver Z (306) is bound toDevice Y, and I/O operations are restarted for the device driver stack.

FIG. 3B shows the exemplary device driver stack in which Driver Z (306)is unbound from Device X (308).

FIG. 3C shows the exemplary device driver stack in which Driver Y (314)is bound to Device X (308) and exports Device Y (312).

FIG. 4 shows the exemplary device driver stack in which Driver Z (306)is bound to Device Y (312), completing the installation of the Driver Y(314) into the device driver stack.

FIG. 5 is a logic flow diagram showing exemplary logic for inserting adevice into a device driver stack. Beginning in step 502, the logicfirst suspends I/O operations for the LU I/O stack, in step 504. Thelogic then unbinds the upper LDD from the lower LDD, in step 506, bindsthe new LDD to the lower LDD, in step 508, and binds the upper LDD tothe new LDD, in step 510. Finally, the logic restarts I/O operations forthe device driver stack, in step 512, and terminates in step 599.

In order to stop using a particular device, the corresponding LDD may beremoved from the device driver stack, specifically from between an upperLDD and a lower LDD already in the device driver stack. Removing theunwanted LDD from the device driver stack involves suspending I/Ooperations for the device driver stack, unbinding the upper LDD from theunwanted LDD, unbinding the unwanted LDD from the lower LDD, binding theupper LDD to the lower LDD, and restarting I/O operations for the devicedriver stack.

FIG. 6A shows an exemplary device driver stack including four LDDs,namely TCD (602), Driver Z (606), Driver Y (610) and Driver X (614).Driver X (614) exports Device X (612). Driver Y (610) is bound to DeviceX (612), and exports Device Y (608). Driver Z (606) is bound to Device Y(608), and exports Device Z (604). TCD (602) consumes Device Z (604).

In order to remove Device Y (608) from the device driver stack, I/Ooperations are suspended for the device driver stack. Then, Driver Z(606) is unbound from Device Y (608), and Driver Y (610) is unbound fromDevice X (612). Finally, Driver Z (606) is bound to Device X (612), andI/O operations are restarted for the device driver stack.

FIG. 6B shows the exemplary device driver stack in which Driver Z (606)is unbound from Device Y (608).

FIG. 6C shows the exemplary device driver stack in which Driver Y (610)is unbound from Device X (612).

FIG. 7 shows the exemplary device driver stack in which Driver Z (606)is bound to Device X (612), thereby eliminating the Driver Y (610) fromthe device driver stack.

FIG. 8 is a logic flow diagram showing exemplary logic for removing adevice from a device driver stack. Beginning in step 802, the logicfirst suspends I/O operations for the device driver stack, in step 804.The logic then unbinds the upper LDD from the unwanted LDD, in step 806,unbinds the unwanted LDD from the lower LDD, in step 808, and binds theupper LDD to the lower LDD, in step 810. Finally, the logic restarts I/Ooperations for the device driver stack, in step 812, and terminates instep 899.

In a preferred embodiment of the present invention, the LDD registrationsystem is used for installing device drivers in a storage unit within acomputer storage system. In a common computer system architecture, ahost computer is coupled to a computer storage system that providesnon-volatile storage for the host computer. The computer storage systemincludes, among other things, a number of interconnected storage units.Each storage unit includes a number of physical or logical storage media(for example, a disk array). For convenience, a group of one or morephysical disks that are logically connected to form a single virtualdisk is referred to hereinafter as a “Logical Unit” (LU). Data from thehost computer is stored in the computer storage system, and specificallyin the various storage units within the computer storage system.

The computer storage system preferably includes redundant systems inorder to ensure data integrity and availability. Specifically, eachstorage unit includes redundant subsystems such as multiple storageprocessors and multiple disks in order to ensure continued operation inthe case of a subsystem failure, and the various storage units in thecomputer storage system interoperate to ensure continued operation inthe case of a complete storage unit failure.

In addition to ensuring continued operation during failures, theinteroperation of the various storage units in the computer storagesystem together with the redundant subsystems within each storage unitenable the various storage units in the computer storage system toprovide many advanced functions. For example, the various storage unitsin the computer storage system can interoperate to maintain redundantcopies of information at geographically disparate locations, and thevarious storage units in the computer storage system can alsointeroperate to perform “load balancing” across the various storageunits in the computer storage system. A remote mirroring function isdescribed in the related U.S. Pat. No. 6,671,705 entitled REMOTEMIRRORING SYSTEM, DEVICE, AND METHOD, which was incorporated byreference above. Such interoperation requires special communicationsbetween the various storage units in the computer storage system, andmore particularly between storage processors running in the variousstorage units.

FIG. 9 shows an exemplary computer system 900 in accordance with anembodiment of the present invention. The exemplary computer system 900includes a host 910 coupled to a computer storage system 920. Thecomputer storage system 920 includes a master storage unit 930 and anumber of slave storage units 940 ₁ through 940 _(N). The host 910 iscoupled to the master storage unit 930. Certain storage functions, suchas remote mirroring, requires each storage unit in the computer storagesystem 900 to maintain a communication link to all of the other storageunits in the computer storage system 900, such that each storage unit iscapable of communicating with all of the other storage units in thecomputer storage system 900.

In a preferred embodiment of the present invention, each of the storageunits in the computer storage system, such as the master storage unit930 and the slave storage units 940 ₁ through 940 _(N) in the computerstorage system 920, is a fault-tolerant RAID (redundant array ofindependent disks) storage unit with redundant management and storagecapabilities. As shown in FIG. 10, a preferred storage unit 1000includes an Administrative Interface 1001, at least one Host Interface1002, at least a first Storage Processor (SP) 1004 and an optionalsecond SP 1008, a number of disks arranged as a Disk Array 1006, and aNetwork Interface 1010. The Administrative Interface 1001 is preferablyan Ethernet interface through which the storage unit 1000 is managed andcontrolled. The Host 910 interfaces with the storage unit 1000 throughthe Host Interface 1002, which preferably emulates a SCSI interface. TheHost Interface 1002 is coupled to the SP 1004 and to the optional SP1008, such that the Host 910 can communicate with both the SP 1004 andthe optional SP 1008. The SP 1004 and the optional SP 1008 areinterconnected through an interface 1009, which is preferably aFibreChannel interface. The SP 1004 and the optional SP 1008 are alsocoupled to the Network Interface 1010 via the interface 1009, whichenables each SP (1004, 1008) to communicate with SPs in other storageunits within the computer storage system 920. The SPs that areinterconnected via the interface 1009 communicate, for example, using aMessage Passing Service as described in the related patent applicationentitled SYSTEM, DEVICE, AND METHOD FOR INTERPROCESSOR COMMUNICATION INA COMPUTER SYSTEM, which was incorporated by reference above.

A preferred SP (1004, 1008) is based upon a commercially availablesingle or multiple processor hardware platform that runs an operatingsystem, such as the Windows NT operating system. Both SPs (1004, 1008)run essentially the same software, although the software can differbetween the two SPs, for example, due to a software upgrade of one butnot the other SP. Therefore, each SP (1004, 1008) is capable ofproviding full management functions for the storage unit.

The SP software requires each LU to be owned and accessed through oneand only one SP at a time. This notion of LU ownership is referred to as“assignment.” The SP software allows each LU in a LU Array Set to be“assigned” to a different SP. During normal operation of the storageunit, both SPs process requests and perform various management functionsin order to provide redundancy for the storage unit. If one of the SPsfails, the other SP takes over management of the LUs for the failed SP.For convenience, the SP that is primarily responsible for managing aparticular group of LUs is referred to hereinafter as the “primary” SP,while other SP is referred to hereinafter as the “secondary” SP. Forpurposes of the following discussion, and with reference again to FIG.10, the SP 1004 will be referred to as the “primary” SP, and the SP 1008will be referred to as the “secondary” SP.

FIG. 11 is a block diagram showing the general architecture of the SPsoftware 1100. As shown in FIG. 11, the SP software is divided into twogeneral categories, specifically User (Configuration) software 1110 andKernel software 1120. The User (Configuration) software 1110 includes,among other things, the management protocol stack (TCP/IP) and alluser-space software. The Kernel software 1120 is divided into twogeneral areas, specifically Host-Side software 1121 and Disk-Sidesoftware 1123. The Host-Side software 1121 emulates a SCSI interface forcommunication with the Host 910 via the Host Interface 1002. TheDisk-Side software 1123 manages the Disk Array 1006 and includes, amongother things, software for coordinating information storage within andamong the various storage units in the computer storage system.

The SP software utilizes layered device drivers to allow softwarefunctions to be dynamically activated or inactivated, specifically byadding or removing software drivers from a device driver stack,respectively. The layered device drivers are managed using bothoperating system services as well as the LDD registration system.Therefore, the Kernel software 1120 preferably includes, among otherthings, a Registry 1122 for registering device drivers with theoperating system.

FIG. 12 shows the SP software architecture in greater detail. As shownin FIG. 12, the Host-Side software 1121 includes a number of components,including a Target Miniport 1202, a Target Class Driver (TCD) 1204, anda Target Disk Driver (TDD) 1206. The Target Miniport 1202 emulates aSCSI interface for the Host Interface 1002 as well as the FibreChannelinterface 1009 for inter-SP communication. The Disk-Side software 1123includes a number of components, including the disk management software1208 and an Initiator Miniport 1210. The Initiator Miniport 1210provides an interface to the Disk Array 1006. The User (Configuration)software 1110 also includes a number of components, including aManagement Agent 1214 for interfacing to a manager (not shown).

In a preferred embodiment of the present invention, each SP runs theWindows NT operating system. Within the Windows NT operating system,when a process makes a call to the Win32 Application Program Interface(API), the call is interpreted by a Windows NT Dynamically LinkedLibrary (DLL) 1302, as shown in FIG. 13. For file or device operations,the DLL 1302 makes a system call, which is handled by the Windows NTInput/Output (I/O) Manager 1304. If the operation is for a file on afile system, then the Windows NT I/O Manager 1304 calls a file systemdriver, which, in this case, is a NTFS Driver 1312. If the NTFS Driver1312 needs to perform input/output operations, then the NTFS Driver 1312makes a call to a disk class driver below it in the stack, which in thiscase is the Windows NT SCSI Disk Class Driver 1316. The call may beintercepted and processed by a Filter Driver 1314 before being processedby the Windows NT SCSI Disk Class Driver 1316. If an I/O operation is toa “raw” disk, then the Windows NT I/O Manager 1304 calls a RAW FileSystem (FS) Driver 1306, which in turn calls the Windows NT SCSI DiskClass Driver 1308. The output from the Windows NT SCSI Disk Class Driver1308 may be processed by a Filter Driver 1310. In either case, theWindows NT SCSI Port Driver 1318 is called to send SCSI commands todevices via the Initiator Miniport 1210.

The components on the Disk-Side 1123 present a standard Windows NT diskclass interface and implement various fault tolerant disk strategies.These various fault tolerant disk strategies are performed by the DiskManagement Software 1208. As shown in FIG. 14, the Disk ManagementSoftware 1208 includes a number of Disk Objects (1404, 1406, 1408) whichare installed as filter drivers in the I/O stacks in order to interceptand process device operations.

The Host-Side software 1121 contains a set of drivers that emulate adisk drive interface, making the storage unit appear to the Host 910 asan external disk drive. The Host 910 controls the storage unit throughthe Host-Side software 1121, although the actual storage is provided bya disk class object from the Disk-Side 1123. FIG. 15 shows therelationship between various Host-Side 1121 components. The Host 910interfaces to the storage unit through the Target Miniport 1202, andspecifically through a SCSI Bus Interface 1522 that is coupled to theHost Interface 1002. The SP interfaces to other SPs through the TargetMiniport 1202, and specifically through a Fibre Channel Interface 1524via the interface 1009. Information communicated to or from the TargetMiniport 1202 is processed by the NT SCSI Port Driver 1520, which makesany necessary conversions to or from SCSI format. The NT SCSI PortDriver is coupled to the Target Class Driver (TCD) 1204, whichessentially connects the Target Miniport 1202 to the actual storage andimplements most of the basic SCSI protocols. The TCD 1204 creates anumber of Virtual Logical Unit (VLU) objects (1504, 1506, 1508), eachrepresenting a LU from the perspective of the Disk-Side software 1123.The Target Disk Driver (TDD) 1206 implements SCSI disk semantics. Itsprimary purpose is to implement Disk Logical Unit (DLU) objects (1512,1514). Each DLU object (1512, 1514) sits on top of a disk class object(1516, 1518) presented by a lower level driver. The TDD 1206 examinesall incoming commands and either services a particular command ordelegates the command to the underlying disk class object.

The various components of the SP are administered through a standardadministrative interface. Each component is associated with acomponent-specific administrative interface through which the componentis configured and controlled. The component-specific administrativeinterface includes, among other things, a library of component-specificadministrative interface functions for the component. Thecomponent-specific administrative interface is essentially a conversionlayer between the standard administrative interface and the privateinterface of the component. For example, the component-specificadministrative interface functions may convert data formats (forexample, between “big-endian” and “little-endian” formats),configuration and control parameter formats, and error codes.

Each LU is associated with an Input/Output stack that includes a numberof device drivers. In order to allow for customization at the I/O levelfor a particular LU, the SP software includes the LDD registrationsystem that allows one or more LDDs to be inserted into the I/O stack ofthe LU. Each LDD emulates a device. A LDD “exports” a device to the LDDabove it in the LU I/O stack, and is “bound” to the device from the LDDbelow it in the LU I/O stack in order to re-layer the device. A LDD mayalso “consume” a device.

More specifically, LDDs create, re-layer, and consume Windows NTdevices. A LDD creates a device by making itself available to be linkedinto the LU I/O stack. Devices must be identified both across layerboundaries and within the context of layer boundaries. Thus, each deviceis identified by both a device name, which is unique only to each stageof re-layering, and a World Wide Name (WWN), which is unique across allstages of re-layering.

Once a device is created, the device is available to be re-layered.Re-layering of an existing device involves binding a LDD to the existingdevice and exporting it with a new device name. FIG. 16 shows are-layered device in an exemplary LU I/O stack. Specifically, the LU I/Ostack includes three layered device drivers, namely TCD (1602), Driver Z(1606), and Driver X (1610). Driver X (1610) creates Device X (1608).Driver Z (1606) binds to Device X (1608) and creates Device Z (1604),thereby re-layering Device X (1608). TCD (1602) binds to Device Z (1604)rather than Device X (1608). A device is typically re-layered by at mostone LDD. The device may be re-layered by the creating LDD or by anotherLDD.

A LDD may also consume a device. Consumption is a term that is used todescribe the allocation of storage resources to the LDD such that thestorage resource are no longer available to other devices or to I/O fromthe host. The host designates a device to be consumed by the LDD via theLDD administrative interface.

It should be noted that a particular LDD, and therefore thecorresponding layer of the LU I/O stack, may be “active” or “inactive.”If the LDD is “active,” then the LDD processes all I/O for the device.If the LDD is “inactive,” then the LDD does not process any I/O for thedevice, and the LDD does not modify the I/O data in any way.

In order to manage the LDDs in the I/O stack, the LDD component includesits own LDD administrative interface. The LDD administrative interfaceincludes a LDD administrative interface library including a number ofLDD administrative interface functions. The LDD administrative interfacefunctions provide for configuration and control of the LDD component,including, among other things, suspending and restarting I/O operationsfor a LU I/O stack, inserting a LDD into a LU I/O stack, removing a LDDfrom a LU I/O stack, and configuring LDD configuration parameters.

In order to utilize a particular device, the corresponding LDD isinstalled into an LU I/O stack using the LDD registration system inconjunction with the operating system device driver registration system.Installing the LDD into the LU I/O stack involves registering the LDDwith both the LDD registration system and the operating system devicedriver registration system.

The Windows NT operating system maintains a list of device drivers andtheir corresponding parameters in the System\CurrentControlSet\Servicesfile. The System\CurrentControlSet\Services file lists all devicedrivers in the system (that is, both layered device drivers belonging toLU I/O stacks and other device drivers), and can be very large. As aresult, it can be difficult for a user or system administrator todetermine from the System\CurrentControlSet\Services file which devicedrivers are the layered device drivers belonging to LU I/O stacks.

Using the information in the System\CurrentControlSet\Services file, theWindows NT operating system can load the device drivers into theoperating system in a specified order. Such loading provides for orderlyinitialization of the device drivers. Unfortunately, the Windows NToperating system cannot set up the LU I/O stacks with proper layeringorder, as required for operation of LDDs in the preferred storage unit.

Therefore, the LDD registration system is used to set up the LU I/Ostacks with proper layering order. The LDD registration system maintainsa number of private files (i.e., separate from the operating systemfiles) in order to keep track of the LDDs that are installed and therelationships between the LDDs. The LDD registration system enables aparticular LDD to be inserted or removed from a LU I/O stack, and inparticular from a specific layer in the LU I/O stack.

Specifically, the SP software maintains a Drivers list and a DriverOrderlist under the Windows NT operating system. The Drivers list is used toidentify the LDDs that are installed, and includes a DriverCountindicating the number of drivers in the list as well as a key for eachdriver. Each key includes an ordinal number, a driver name, a libraryname, a stack operations parameter, and an I/O initiator parameter. TheDriverOrder file is used to specify the relative position of the LDDswith device driver stacks, and includes a DriverCount indicating thenumber of drivers in the list as well as a key for driver. Each keyincludes an ordinal number and a driver name.

In order to utilize a particular device, a new LDD is installed at thespecified relative position in the LU I/O stack, specifically between anupper LDD and a lower LDD already in the LU I/O stack. Installing thenew LDD into the LU I/O stack involves suspending I/O operations for theLU I/O stack, unbinding the upper LDD from the lower LDD, binding thenew LDD to the lower LDD, binding the upper LDD to the new LDD, andrestarting I/O operations for the LU I/O stack.

In order to stop using a particular device, the corresponding LDD may beremoved from the LU I/O stack, specifically from between an upper LDDand a lower LDD already in the LU I/O stack. Removing the unwanted LDDfrom the LU I/O stack involves suspending I/O operations for the LU I/Ostack, unbinding the upper LDD from the unwanted LDD, unbinding theunwanted LDD from the lower LDD, binding the upper LDD to the lower LDD,and restarting I/O operations for the LU I/O stack.

The administrator or network manager configures LU I/O stacks byinvoking various administrative interface functions. The administrativeinterface functions provide for suspending and restarting I/O operationsfor an LU I/O stack, binding and unbinding drivers, and passing privatemanagement data to the LDD for the purpose of configuring the parametersfor LDD operation. The administrative interface function for unbinding adriver includes a parameter for indicating whether or not the driverwill be re-bound to another driver.

In order to insert a LDD into an LU I/O stack, the administrator ornetwork manager invokes the appropriate administrative interfacefunctions to suspend I/O operations for the LU I/O stack, unbind theupper LDD from the lower LDD (with an indication that the upper LDD willbe re-bound), bind the upper LDD to the new LDD, bind the new LDD to thelower LDD, and restart I/O operations for the LU I/O stack.

In order to remove a LDD from the LU I/O stack, the administrator ornetwork manager invokes the appropriate administrative interfacefunctions to suspend I/O operations for the LU I/O stack, unbind theupper LDD from the unwanted LDD (with an indication that the upper LDDwill be re-bound), unbind the unwanted LDD from the lower LDD (with anindication that the unwanted LDD will not be re-bound), bind the upperLDD to the lower LDD, and restart I/O operations for the LU I/O stack.

In a preferred embodiment of the present invention, predominantly all ofthe layered driver administration logic is implemented as a set ofcomputer program instructions that are stored in a computer readablemedium and executed by an embedded microprocessor system within thestorage processor. Preferred embodiments of the invention may beimplemented in any conventional computer programming language. Forexample, preferred embodiments may be implemented in a proceduralprogramming language (e.g., “C”) or an object oriented programminglanguage (e.g., “C++”). Alternative embodiments of the invention may beimplemented using discrete components, integrated circuitry,programmable logic used in conjunction with a programmable logic devicesuch as a Field Programmable Gate Array (FPGA) or microprocessor, or anyother means including any combination thereof.

Alternative embodiments of the invention may be implemented as acomputer program product for use with a computer system. Suchimplementation may include a series of computer instructions fixedeither on a tangible medium, such as a computer readable media (e.g., adiskette, CD-ROM, ROM, or fixed disk), or fixed in a computer datasignal embodied in a carrier wave that is transmittable to a computersystem via a modem or other interface device, such as a communicationsadapter connected to a network over a medium. The medium may be either atangible medium (e.g., optical or analog communications lines) or amedium implemented with wireless techniques (e.g., microwave, infraredor other transmission techniques). The series of computer instructionsembodies all or part of the functionality previously described hereinwith respect to the system. Those skilled in the art should appreciatethat such computer instructions can be written in a number ofprogramming languages for use with many computer architectures oroperating systems. Furthermore, such instructions may be stored in anymemory device, such as semiconductor, magnetic, optical or other memorydevices, and may be transmitted using any communications technology,such as optical, infrared, microwave, or other transmissiontechnologies. It is expected that such a computer program product may bedistributed as a removable medium with accompanying printed orelectronic documentation (e.g., shrink wrapped software), preloaded witha computer system (e.g., on system ROM or fixed disk), or distributedfrom a server or electronic bulletin board over the network (e.g., theInternet or World Wide Web).

Thus, the present invention may be embodied as a device, such as acomputer, a storage unit, or a storage processor for operation in astorage unit, having an operating system device driver registrationsystem and a layered device driver registration system. The layereddevice driver registration system enables a user to associate a devicedriver with one of a number of device driver stacks and to configure therelative position of the device driver within the device driver stack.The layered device driver registration system includes a driver fileincluding a first key for the device driver, said first key including adriver name for the device driver and a library name indicating anadministrative library for the device driver. The layered device driverregistration system also includes a driver order file including a secondkey for the device driver, said second key including a driver name forthe device driver and an ordinal value indicating the relative positionof the device driver within the device driver stack.

The present invention may also be embodied as a method of utilizing adevice driver in a computer storage device involving registering adevice driver with an operating system device driver registration systemand registering the device driver with a layered device driverregistration system. Registering the device driver with the layereddevice driver registration system involves adding the device driver to adriver list and specifying a relative position for the device driverwithin a device driver stack. More specifically, adding the devicedriver to the driver list involves adding a first key to a driver filemaintained by the layered device driver registration system, said firstkey including a driver name for the device driver and a library nameindicating an administrative library for the device driver, whilespecifying the relative position for the device driver within a devicedriver stack involves adding a second key to a driver order filemaintained by the layered device driver registration system, said secondkey including a driver name for the device driver and an ordinal valueindicating the relative position of the device driver within the devicedriver stack.

The method also allows the device driver to be inserted at the specifiedrelative position in the device driver stack. Specifically, insertingthe device driver at the specified relative position in the devicedriver stack involves finding within the device driver stack an upperdevice driver above the specified relative position that is bound to afirst device that is exported by a lower device driver below thespecified relative position, suspending input/output operations for thedevice driver stack, unbinding the upper device driver from said firstdevice, binding the device driver to said first device, binding theupper device driver to a second device that is exported by the devicedriver, and restarting input/output operations for the device driverstack.

The method also allows the device driver to be removed from the devicedriver stack. The device driver stack includes an upper device driverbound to a first device exported by the device driver and the devicedriver bound to a second device exported by a lower device driver.Removing the device driver from the stack involves suspendinginput/output operations for the device driver stack, unbinding the upperdevice driver from said first device, unbinding the device driver fromsaid second device, binding the upper device driver to said seconddevice, and restarting input/output operations for the device driverstack.

The present invention may be embodied in other specific forms withoutdeparting from the essence or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive.

1. A method for dynamically adding a device driver into a layered stackof device drivers in a computer system comprising: responsive to aparameter indicating at least one device driver in the layered stackinitiates I/O, suspending I/O operations for the layered stack: duringsaid suspension of I/O operations for the layered stack: unbinding anupper driver in the stack from a lower driver in the stack; binding thedevice driver to the lower driver to form a layered device; and bindingthe upper driver to the layered device; and thereafter, restarting I/Ooperations for the layered stack.
 2. The method of claim 1, wherein thecomputer system comprises an operating system and a layered devicedriver registration system, and wherein the method further comprises:registering the device driver with the operating system; and registeringthe device driver with the layered device driver registration system. 3.The method of claim 2 wherein registering the device driver with thelayered device driver registration system includes adding a key to adriver file maintained by the layered device driver registration system,said key including an I/O initiator parameter indicating whether thedevice driver initiates I/O.
 4. A method for dynamically removing adevice driver from a layered stack in a computer system comprising:responsive to a parameter indicating at least one device driver in thelayered stack initiates I/O, suspending I/O operations for the layeredstack: during said suspension of I/O operations for the layered stack;unbinding an upper driver in the stack from the device driver; unbindingthe device driver from a lower driver; and binding the upper driver tothe lower driver; and thereafter, restarting I/O operations for thelayered stack.
 5. The method of claim 4 wherein the lower driveremulates a device, the device having a first device name and furthercomprising exporting the device under the first device name to the upperdriver for use in the layered stack.
 6. The method of claim 4, whereinthe computer system is a computer storage system, and wherein thelayered stack is a logical unit input/output stack.
 7. A computerprogram product, for use on a computer system, for managing a layeredstack of device drivers, the computer program product comprising:program code for determining whether at least one device driver in thelayer stack initiates I/O, and if so, suspending I/O operations for thelayered stack; program code, operational upon suspension of I/Ooperations for the layered stack, for unbinding an upper driver in thestack from a lower driver in the stack; program code for binding thedevice driver to the lower driver to form a layered device; program codefor binding the upper driver to the layered device; and program code,operational upon said binding of the upper driver to the layered device,for restarting I/O operations for the layered stack.
 8. A computerprogram product, for use on a computer system, for managing a layeredstack of device drivers, the computer program product comprising:program code for determining whether at least one device driver in thelayered stack initiates I/O, and if so, suspending I/O operations forthe layered stack; program code, operational upon suspension of I/Ooperations for the layered stack, for unbinding an upper driver in thestack from the device driver: program code for unbinding the devicedriver from a lower driver; program code for binding the upper driver tothe lower driver; and program code, operational upon said binding of theupper driver to the lower driver, for restarting I/O operations for thelayered stack.